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Abstract 

In previous work, we introduced the notion of functional strategies: first-class generic functions that 
can traverse terms of any type while mixing uniform and type-specific behaviour. Functional strategies 
transpose the notion of term rewriting strategies (with coverage of traversal) to the functional program- 
ming paradigm. Meanwhile, a number of Haskell-based models and combinator suites were proposed to 
support generic programming with functional strategies. 

In the present paper, we provide a compact and matured reconstruction of functional strategies. We 
capture strategic polymorphism by just two primitive combinators. This is done without commitment 
to a specific functional language. We analyse the design space for implementational models of func- 
tional strategies. For completeness, we also provide an operational reference model for implementing 
functional strategies (in Haskell). We demonstrate the generality of our approach by reconstructing rep- 
resentative fragments of the Strafunski library for functional strategies. 

1 Introduction 

In Ip^], we introduced the notion of functional strategies for which we assume the following matured 
definition throughout this paper: 

Definition 1 Functional strategies are functions that 

1. are generic, 

2. can mix uniform and type-specific behaviour, 

3. can traverse terms, and 

4. are first-class citizens. 

Functional strategies go beyond parametrically polymorphic functions because of the abilities to traverse 
terms and to dispatch to type-specific behaviour We call this extra polymorphism simply 'strategic poly- 
morphism' . In the present paper, we will capture strategic polymorphism by just two fundamental function 
combinators. Most of our presentation will avoid commitment to a specific functional language, but we 
ultimately define a Haskell-based reference model. 

Functional strategies were derived from the notion of (typed) term rewriting strategies |^, |TJ ^ ^ . 
In fact, the notion of (traversal) strategies can be amalgamated with different programming paradigms. 
We use the term strategic programming for generic programming with strategies in whatever language. 
It is at the heart of strategic programming that traversal schemes are programmer-definable. The native 
application domain of strategic programming is language processing, in particular, the implementation of 
functionality for program transformations and analyses; see | ]2^ |2l| , |2q ] for a few typical applications. 
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With strategies, one can operate on large syntaxes or formats in a scalable and flexible manner. Scalability 
is implied by genericity, and flexibility by a combinator style that enables the definition of appropriate 
traversal schemes. In fact, the ability to traverse terms while mixing uniform and type-specific behaviour is 
beneficial in almost every non-trivial software application. This is demonstrated in [^, where an approach 
to general purpose generic programming is based on original expressiveness for 'strategic polymorphism'. 

Our efforts to amalgamate strategic and functional programming are scoped by the Strafunski project.]] 
Distributions of the Haskell-centred Strafunski bundle for generic programming and language processing 
include generative tool support that, given the programmer-supplied datatypes, generates the code needed 
for strategic programming. In previous work, we came up with different models of functional strategies [|5} 
^0| ]. These models differ regarding the selection of primitive combinators and their types, but they all share 
Haskell as the base language. 

In the present paper, we capture strategic polymorphism by just two combinators: 

• adhoc for type-based function dispatch, and 

• hfoldr for folding over constructor applications. 

The combinator couple adhoc and hfoldr was identified in [|20|], and a very similar couple was employed 
in []23[].p| In the present paper, we use these two combinators for a very compact and matured reconstruction 
of functional strategies. Our goal here is to avoid an invasive commitment to Haskell. Also, we want to 
clearly maintain the link to strategic programming as it was initiated in the context of term rewriting. 
The above two combinators can be mapped to Def. 1 as follows. The combinator adhoc is crucial for 
mixing uniform and type-specific behaviour. It can be considered as a disciplined form of type case. The 
combinator hfoldr is the mother of all (one-layer, i.e., non-recursive) traversal. It folds over the immediate 
subterms of a constructor application — very much in the style of a list fold. This turns traversal schemes 
into programmable entities where ordinary recursive function definition suffices to complete folding into 
recursive traversal. 

The paper is structured as follows. In Sec. ||, we approach to the essential expressiveness for strategic 
polymorphism via a motivating example. In Sec. ^ we define the two key combinators for strategic poly- 
morphism. In Sec. ^, we discuss models of functional strategies. Sec. I and Sec. ^ are largely language- 
independent. In Sec. H, we provide a reference model to extend Haskell with our two combinators. In 
Sec. ^ we demonstrate the power that results from our language extension by reconstructing representative 
parts of Strafunski's library. In Sec. 0, the paper is concluded. 



2 Strategic polymorphism — a motivating example 

We choose a simple but challenging example that demonstrates all the characteristics of functional strate- 
gies. We will define a combinator query with an argument /, such that query f performs a top-down, 
left-to-right traversal to find a subterm that can be processed by / so that a value is extracted from the 
subterm. A suitable subterm has to meet two criteria. Firstly, its type must coincide with the domain of /. 
Secondly, / applied to the subterm should not fail, that is, it should not return Nothing. 

This is the Haskell type of the query combinator: 

query :: Va f3 u. {Term a, Term (5) 

=^ (a ^ Maybe u) — Recogniser / extractor 

— » /3 — Input term 

— » Maybe u — Found entity (if any) 



Strafunski home page: http : / / www . cs . vu . nl/ Strafunski / — 3tra refers to strategies, fun refers to functional 



programming, and their harmonious composition is a homage to the music of Igor Stravinsky. 

'There are tiny technical differences. In Jl^], first-class polymorphism is employed as opposed to proper rank-2 function types in 
the present paper and in |E3||. Also, in |E3||, type cast is favoured as opposed to function dispatch in the present paper and in |2Cj|. 
FurtherroDre, in [p3|, a left-associative fold combinator is used as opposed to the right-associative combinator in the present paper 
and in Igg]. 
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There are three universally quantified type parameters:^ 

• a denotes the type of 'relevant' subterms from which a value is extracted. 

• (3 denotes the type of the term that is eventually passed to query. 

• u denotes the type of the extracted value. 

The first argument of query is a function of type a Maybe u that is meant to interrogate subterms of type 
a to extract a value of type u. The second argument is the input term of type (3. The result type of query 
is the extracted value u (if any), wrapped in the partiality monad Maybe. There are two class constraints 
Term a and Term (3 which point out that a and (3 are place-holders for term types. The Haskell type class 
Term hosts expressiveness for 'strategic polymorphism', that is, basically the two combinators adhoc and 
hfoldr as we will say later 

Before we describe the actual definition of query, let us first point out that this sort of function is useful for 
all kinds of scenarios in program transformation and analysis: 

• Query the type of an abstraction. For instance, from a Java class declaration one may want to retrieve 
the signature of a method with a given name. 

• Query the definition of an abstraction. For instance, from an XML DTD, one may want to retrieve 
the content specification of a declared element type. 

• Query the focused entity in the course of refactoring. For example, from a Cobol program, one may 
want to retrieve a focused group of data description entries. 

One can easily think of numerous variations on query that are equally useful, e.g., implementing bottom-up 
search, or transforming terms rather than querying them, and so on. 

Let's turn to the Haskell definition of the query combinator: 

query f x 



case 



adhocMTU (const Nothing) f x ot - Attempt / 



Just u — > Just u — Done 



Nothing oneMTU {query /) x — Recurse 



We boxed the two combinators that involve strategic polymorphism. (adhocMTU is a type-specialised 
variant of adhoc, and oneMTU is defined in terms of hfoldr as we will show later) For clarity, their 
names end on ''MTV" to remind us of the strategy type at hand: Monadic Type-f/nifying. Monadic style 
is in place here because of the partiality of querying. By 'type unification' we mean that querying returns 
a value of a specific type, regardless of the type of the input term. The combinator adhocMTU is used 
to attempt an application of / to the input term x. The composed function behaves like the polymorphic 
function const Nothing passed as the first argument to adhocMTU except for the type a handled by the 
function /. If the attempt to apply / results in a value u (first branch of case), the search is done, and u is 
returned. Otherwise (second branch of case), the combinator oneMTU is used to call query recursively on 
the children of x, i.e., its immediate subterms. The oneMTU combinator is meant to attempt application of 
its argument to each child in left-to-right order, and returns the result of the first application that succeeds. 
We will later see that oneMTU is just one example of many 'one-layer' traversal combinators — they can 
all be defined in terms of the fundamental combinator hfoldr. 

To summarise, the query combinator illustrates all characteristics of strategies (recall 1.^. in Def. 1): 

1 . The aspect that the query combinator is generic, i.e., applicable to all term types, is expressed by the 
universally quantified j3 in its type. 



^For the purpose of a homogeneous notation, we always use explicit (top-level) universal quantification in all Haskell type signa- 
tures. Note: the type of query is just a plain rank-1 type, that is, all type variables are indeed quantified at the top-level. We will later 
also employ rank-2 types, and thereby go beyond Haskell 98. Rank-2 types make explicit quantification mandatory. So we decide to 
switch to explicit quantification all-over the place. 
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2. The aspect that the query combinator mixes uniform and type-specific behaviour is reflected by the 
appUcation of the combinator adhocMTU . 



3. The aspect that the query combinator traverses the input term is reflected by the recursive definition 
of query in terms of the traversal combinator oneMTU . 

4. first-class status of functional strategies is illustrated by their featuring as combinator arguments 
(cf. the first argument of adhocMTU and oneMTU). 



We refer the reader to gjj, 26 1 for many more examples of strategic polymorphism. The present 
example has been carefully chosen to cover all aspects of strategic polymorphism, and to be representative 
for strategic programming. 



3 Just two combinators for strategic polymorphism 

In the sequel, we define the two combinators adhoc and hfoldr for strategic polymorphism. The definition 
is language-independent. We use a semi-formal style for the semantics of the combinators, and we use rank- 
2 types to assign types to the combinators. The interested reader is referred to for a formal definition 
of typed rewriting strategies in a basically first-order and many-sorted term-rewriting setting. The below 
definition makes heavy use of higher-orderness and polymorphism. This is the key to capturing strategic 
expressiveness in just two dedicated combinators as opposed to the several combinators in previous work. 

The adhoc combinator for type-based function dispatch 

We want to give a single definition of adhoc, which is valid for all different types of functional strategies 
(think of querying vs. transformation). So we assume the general type scheme Va. a ^ c a for functional 
strategies. Here, c is a type constructor that derives the co-domain of the function type from the domain 
a. If we instantiate the co-domain constructor c with the identity type constructor (i.e., I a = a), we 
obtain the type of type-preserving strategies. The constant type constructor (i.e., C u a ^ u) handles the 
type-unifying scheme (i.e., the result type is always u regardless of the input type a). We use an over-lined 
version V of the universal quantifier V to distinguish 'strategic polymorphism' from ordinary parametric 
polymorphism. 

Co-domain constructor 
Term type of specific functionality 
Generic default 
Type-specific ad-hoc case 
Constructed strategy 

„ ( mx, if typeOf(x) = domOf(m) 

adhoc pmx ^ I ' . ^ ' ^ ' 

y p X, otherwise 

The placing of the various V quantifiers in the (rank-2) type of adhoc emphasises that the combinator 
constructs a polymorphic function from a polymorphic function argument p and a monomorphic function 
argument 7ti.[| In the definition, the expressions typeOf{x) and domOJ {m) denote the specific type of x 
and the specific domain of m, i.e., the respective types to which 7 and (3 are instantiated at run-time. So, 
following this definition, adhoc p m x dispatches to the monomorphic m if m is applicable to the x at 
hand, but otherwise it resorts to the polymorphic, generally applicable p. 

In strategic programming, the common usage of adhoc is to derive generic 'rewrite steps' from type- 
specific ones [Q. The monomorphic ingredient m is then a function which rewrites terms of a specific 

Reminder: V/V quantifiers expand to the right as far as possible. Lifting the V7 to the top of the function type would be acceptable, 
because V7 is placed on the right of the outermost — >, and hence, lifting leads to an equivalent type. By contrast, moving the inner 
Vo to the top would lead to a too liberal function that also accepted monomorphic arguments for p. Dually, pushing the V/3 to the 
second argument (where it is used) would lead to a too restrictive function that insisted on polymorphic ad-hoc cases for m instead 
of type-specific functionality. 



adhc 



Vc. 

(Va. 

(V7. 



a ^ ca) 
>c/3) 
7 ^ C7) 
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type, potentially based on pattern matching, whereas the polymorphic ingredient p provides a trivial generic 
default. As a simple example, consider the following polymorphic function negbool which behaves like 
the identity function by default but applies Boolean negation "-i" when faced with a Boolean; 

negbool ~ adhoc id (^) 

For this type-preserving strategy, the co-domain type constructor c is instantiated to the identity type 
constructor /. In our query sample, adhoc was used to construct a type-unifying generic rewrite step 
"adhoc {const Nothing) /". Here, the co-domain constructor c is instantiated to the constant type con- 
structor C. The generic default const Nothing models the failure of the query. The function / interrogates 
terms of a certain type to extract a Maybe value. 



The hfoldr combinator for folding over constructor applications 

Let us recall the basic idiom of list traversal. Without loss of generality, we consider right-associative list 
traversal. Folding a list [xi,X2, ■ ■ ■ , Xn] according to ingredients / and z for the non-empty and the empty 
list form is defined as usual: 

foldr f z [xi,X2, . . . ,a;„] = f xi (f X2 {■ ■ ■ if x„ z) ■ ■ •)) 

Folding over constructor applications is similar: instead of folding over the elements of a homogeneous 
list, we fold over the children of a term, i.e., its immediate subterms. Since the children of a term are 
potentially of different types, we need a heterogeneous fold. So we use the name hfoldr. Without loss of 
generality, we assume curried constructor applications. Folding a term C Xn ■ ■ ■ a;2 a;i is now defined as 
follows: 

hfoldr : Vc. — Co-domain constructor 

(VaV/3. a c {a 13) c (3) — 'cons' case 
(V7. 7^07) — 'nil' case 

(V5. 5 — > c (5) — Constructed strategy [ii] 

hfoldr f z{C Xn ■■■ I2 a:i) = f Xi [f X2 {■ ■ ■ (/ Xn [z C)) ■ ■ ■)) 



The indices in C x„ ■ • • X2 xi clarify that we treat the children in the curried expression as a 'snoc list' 
with the rightmost child as 'head' . Also note that the empty constructor application C is passed to z so that 
the constructor can contribute to the result of folding. The type of hfoldr is somewhat involved, especially 
regarding the argument /. Here, a denotes the type of the current head Xi, i.e., the next subterm, and /3 
denotes the type of a fragment of C a;„ • • • Xi. The type c{a ^ f3) denotes the recursively processed tail, 
and it reflects that this tail lacks the i*^ child of type a. The type of hfoldr's argument z of hfoldr is less 
of a headache. Since z is meant to process constructors, the 7 in its type denotes the type of the constructor 
C, applied to no children. 

This folding operation is now sufficient to define arbitrary one-layer traversal combinators which in turn 
can be completed into recursive traversal schemes in different ways. In the sample section, we assumed a 
one-layer traversal combinator oneMTU which can now be defined concisely as follows: 

oneMTU s = hfoldr (Xh t t ^mplus^ s h) [const mzero) 

Here we assume an extended monad with operations mplus for a kind of choice, and mzero for failure. 
The Maybe monad is a typical representative of this class of monads. The definition states that the argu- 
ment strategy s is applied to the head h of the constructor application, and mplus is used to combine the 
recursively processed tail t and the processed head. Folding starts from mzero. In Sec. ||, we will pro- 
vide definitions of more one-layer traversal combinators, and we derive several typical recursive traversal 
combinators — just in the same way as query was derive from oneMTU by means of ordinary recursive 
function definition. 



5 



4 Implementational models 



— a detailed analysis 



The two combinators adhoc and hfoldr, which capture strategic polymorphism, can be modelled in several 
ways. In this section, we will analyse the dimensions of this design space for implementation. This also 
allow us to refer to the large body of related work on generic programming. The exploration will avoid 
commitment to a specific functional language. This will clarify that different typed functional languages 
can be made fit for strategic programming, e.g.. Clean, Haskell, and SML. 



Models at a glance 

As with any generic functionality, there are three ways to enable functional strategies in a given language; 

built-in The combinators adhoc and hfoldr are implemented as language primitives. 

defined They are defined in terms of already available expressiveness. 

per-type They are defined using a term interface which is implemented per datatype. 

Let us make some important side remarks regarding these overall approaches. The built-in option is the 
preferred one but it requires changing the language and its implementations. The defined option may fail 
to be faithful or may require inconvenient encodings, depending on the given expressiveness (as demon- 
strated below). To be practical and scalable, the per-type option needs generative tool support to im- 
plement the term interface per datatype. If the generative component becomes an integral part of the 
language implementation (as is the case for other generic functionality, e.g., equality predicates in SML 
and Haskell 98 [|9|), the per-type option evolves into the built-in option. 

Whichever option is chosen, another seven dimensions span a design space: 

type reflection How to query type information and how to perform coercion? 

term reflection How to generically destruct and construct terms? 

application How to apply a strategy to an actual term? 

quantiflcation How to separate strategic and parametric polymorphism? 

ranking How to rank the types of strategy combinators? 

reduction How to deal with eager vs. lazy reduction and with effects? 

modularisation How to maintain separate compilation? 



The type-reflection dimension 

Type-based function dispatch (adhoc) assumes some type information at run-time. In addition, coercion 
of type-specific cases is needed to apply them to terms encountered at run-time. Dynamic typing ^ ||] 
provides expressiveness to define adhoc. Then, the terms that are processed by strategies had to be of type 
Dynamic, and adhoc is implemented by 'dynamic type case' for type matching and coercion. (There are 
few language implementations with built-in support for dynamic typing but Yale Haskell used to support 
it, and it was recently added to Clean. Per-type support for dynamic typing has been suggested in various 
ways.) In fact, dynamic typing is more powerful than needed for adhoc because it involves the special 
type Dynamic. A lightweight dynamic-typing approach is to maintain a universe in which all datatypes 
are embedded [p4|]. This approach is particularly suited for per-type generative support. Embedding 
can be performed in two ways: either via a constructor per type [^], or on the basis of a universal term 
representation that includes a type representation [^. As an alternative to dynamic typing, one may 
also consider intensional polymorphism [|l2|, Q as a means to define adhoc. This is a major language 
extension. (It is not available in widespread language implementations.) More seriously, this approach 
is not applicable because all work in the area of intensional type analysis favours structural type analysis 
while our kind of dispatching requires nominal type analysis as argued in | pl] , |23[ ]. This closes the case to 
define adhoc in terms of other expressiveness. As for a built-in adhoc, the following approaches are at our 
disposal. Access to run-time type information can be based on a term representation with type tags [OH]. 
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We should note that such tags are in conflict with type erasure. Also, they slightly enlarge the run-time 
representation of terms, and in turn slow down term manipulation. Alternatively, term constructors can 
be used to retrieve type information via a mapping from constructors to type tags. Yet another approach 
is to rely on carrying dictionaries in the sense of type classes [ p8[ ] instead of carrying types in the terms 
themselves. Yet another approach is to rely on run-time type information complemented by unsafe type 
coercion as discussed in [p3|]. 



The term-reflection dimension 

The poor man's way to observe term structure is based on a universal term representation. Here, explo- 
sion and implosion functions mediate between the programmer-supplied datatypes and the universal term 
representation. This expressiveness is usually provided per-type ||5| Folding over constructor ap- 
plications boils then down to ordinary folding over homogeneous lists of term representations. Note that 
it is imperative to effectively hide the representation type in order to guarantee 'implosion safety' [|2^]. 
Then, this approach shines because of its simplicity. Note that implosion and explosion are likely to lead 
to a performance degradation but the choice of a suitable representation type can limit the depth of term 
conversion to a traversal's extent. A built-in definition of hfoldr would entirely avoid this rather indirect 
style of operating on terms. In fact, built-in support is straightforward: Def. [ii] can be defined on any 
run-time term representation as is. As our Haskell-specific reference model of the upcoming section will 
demonstrate, term reflection can also be supported elegantly per-type. That is, hfoldr directly operates 
on terms on the basis of a per-type implementation of Def. [ii]. The most prominent expressiveness to at- 
tempt a definition of hfoldr is presumably polytypism [ [l8[ [l6| , pj[ p4[ |l5} ||] as implemented in PolyP and 
Generic Haskell. The combinator hfoldr can indeed be expressed by structural induction on the type for 
its traversed argument. However, nominal run-time type case as needed for adhoc is beyond the scope of 
polytypism. The various constructs to customise polytypic definitions^ are compile-time means as opposed 
to a combinator for run-time type-based dispatch. One may also consider recent proposals for generalised 
pattern-match constructs | ]l7[ ^] to define hfoldr. Pattern matching is then not restricted to a single type, 
and a pattern-match case does not insist on a specific constructor Again, these approaches do not offer 
type case. 



The application dimension 

Ideally, strategies are plain functions on the programmer's term types. In fact, this characterises a challeng- 
ing corner in our multi-dimensional design space. There are the following reasons why strategy application 
might deviate from function application, (a) Strategies might operate on Dynami c or a representation type 
in the interest of type and/or term reflection, (b) Strategies might be wrapped inside datatype constructors 
for reasons of opaqueness [|5]l, or for reasons of rank-2 polymorphism [pO|]. (c) Strategies might operate 
on datatypes constructed from term types for reasons of a uniform definition 23 1: recall the co-domain 



constructor c in Def. [i] and Def. [ii]. This constructor will be normally a proper datatype because type- 
level lambdas are hardly supported in functional programming. Strategy application differs for (a)-(c). As 
for (a), to deal with Dynami c or a representation type, the ordinary terms need to be converted before and 
after strategy application. For convenience, this can be encapsulated via an overloaded application opera- 
tor [p^. Then the programmer does not need to provide type tags. As for (b), a corresponding application 
operator is trivially defined by unwrapping. Basic strategy combinators also need to perform wrapping and 
unwrapping all-over the place. As for (c), we are saved by the fact that usually only a small number of 
co-domain constructors are used. Hence, one can specialise the types of adhoc and hfoldr for these few 
cases instead of postponing the type adjustment until strategy application. The built-in approach can hide 
this problem via a closed-world assumption regarding co-domain constructors. 

'Cf. ad-hoc definitions for Generic Hasl^ell as of type-specific instances for derivable type classes jl^. H i just as for ordinary 
Haskell type or constructor classes Jj^, copy lines and constructor cases added to Generic Haskell as ofp^ 
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The quantification dimension 



It is clear that strategies go beyond parametrically polymorphic functions. To reflect this fact, we used V 
instead of V in Def. [i] and Def. [ii]. In an actual language design, we can extend the interpretation of the 
universal quantifier, i.e., we equate our V with V. This is common practice for intensional polymorphism. 
We introduced V for the sake of a clear separation of parametric and strategic polymorphism. Having in 
mind a per-type approach, we can also introduce explicit type constraints in the sense of ad-hoc polymor- 
phism [32|, as supported by Haskell and Clean, i.e., we equate Va. . . . with Va. Term a ^ .... Thus, 
the class constraint Term a points out where we go beyond parametric polymorphism. A built-in approach 
does not rely on type classes or class constraints. 



The ranking dimension 

To enable the combinator style of strategic programming, it is indispensable that strategy combinators con- 
sume polymorphic arguments. The most basic example is the hfoldr combinator which must insist on a 
polymorphic first argument because it is applied to children of potentially different term types. Normally, 
the need for polymorphic function arguments necessitates second-order polymorphism [ p^ ^ as opposed 
to 'simple' polymorphism with top-level quantification. One can attempt to organise generic traversal in 
terms of rank-1 expressiveness | ]l7| | but this will rule out the key idioms of strategic programming — in 
particular one-layer traversal. As an aside, second-order polymorphism is generally avoidable if strategies 
are weakly typed as functions on a representation type. Some form of rank-2 types (or even higher ranks) 
are supported in several functional language implementations. A well-understood form is first-class poly- 
morphism [|l9| as employed for modelling functional strategies in [|20|]. First-class polymorphism means 
to wrap up polymorphic functions as constructor components. This necessitates unwrapping prior to func- 
tion application. In [p3|], we employ rank-2 types (as supported in the current GHC implementation of 
Haskell) for generic traversal combinators. Regarding the earlier discussion of expressiveness to define 
our combinators, we should now add that 'second order' is also indispensable if existing forms of polymor- 
phism were considered. In particular, polytypism in Generic Haskell Jl^ Q is not second order because 
polytypic functions cannot involve polytypic function arguments. 



The reduction dimension 

Functional strategy combinators were inspired by term rewriting strategies which are eager. As 

for ordinary function application, the eager functional programmer can effectively postpone strategy appli- 
cation by the lazy "i/" in the definition of new strategy combinators. When adding the hfoldr combinator 
in an eager framework, Def. [ii] must be implemented with some care to prevent premature evaluation of 
applications to subterms. This is not a problem in a straightforward inductive implementation (as opposed 
to the maybe too eager reading of Def. [ii]). There is also no problem with using impure effects such as 
in SML rather than monadic effects. This is again demonstrated by strategic term rewriting a la Stratego 
because Stratego supports some effects, e.g., for hygenic name generation or I/O. 



The modularisation dimension 

Strategic programs do not require compile-time specialisation of generic functionality as opposed to poly- 
typic programs. This is because strategic programs operate on the programmer-supplied datatypes only via 
adhoc and hfoldr. These combinators, in turn, either operate on suitable run-time term representations as 
built-ins, or they are overloaded per-type. Hence, separate compilation is maintainable. Some techniques 
for type or term reflection might however imply a closed-world assumption. Firstly, the definition of a 
universe with embedding constructors per type is not extensible unless we assume extensible datatypes. 
In [pO|, we deal with the same problem: type case is encoded in a way that relies on a class member per 
term type. Separate compilation is also sacrificed when one provides per-type functionality by a 'mon- 
ster switch', that is, by a central authority which would be meant to cover all types as opposed to proper 
overloading with support for separate compilation. 
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5 A reference model for Haskell 



We will now define a Haskell-based reference model for the implementation of the combinators adhoc and 
hfoldr. In view of the previous section, we can provide the following characterisation: 

• The reference model relies on per-type functionality. 

• Strategies directly operate on the terms of the programmer-supplied datatypes. 

• Strategy application is plain function application. 

To start with, we define the type scheme for generic functions that model strategies: 

type Parametric a c = q — > c a 

type Strategic c — Va. Term a ^ Parametric a c 

These two type synonyms make a distinction between unconstrained, i.e., parametrically polymorphic 
functions and constrained, i.e., strategically polymorphic functions. The class constraint points out where 
we go beyond parametric polymorphism. Roughly, the Term class hosts our two combinators, but the 
details follow below. Let us first list the Haskell types of our two combinators: 

adhoc :: Vc a. Term a => Strategic c Parametric a c ^ Strategic c 
hfoldr :: Vc. HCons c —^ HNil c Strategic c 

type HCons c = Va [3. Term a=^a— >c(a— >c/3 
type HNil c = V7. 7 — > c 7 

The two type synonyms above are defined for convenience to make the type of hfoldr more comprehen- 
sible. In the types of the combinators, we make use of rank-2 polymorphism as provided by the GHC 
implementation of Haskell. It remains to define the combinators, to provide the complete declaration of 
the Term class, and to describe the derivation of the Term instances. We start with the implementation 
of Def. [i] for adhoc. To this end, we assume an operation typeOf which maps 'typeable' values of any 
term type to a type representation. Note that this is the kind of mapping that we proposed earlier in order 
to avoid carrying type information in the terms themselves. The operation typeOf is placed in a Typeable 
class as follows: 

class Typeable a where 
typeOf :: a — > TypeRep 

The type TypeRep models type representations. Furthermore, we assume an operation unsafeCoerce to 
cast a value of any type to another type. Then, Def. [i] can be rephrased in Haskell as follows: 

adhoc p m X ~ li [typeOf x) = {domOf m) then {unsafeCoerce m) x else p x 
domOf (f ■.■.a^b) = typeOf (_L :: a) 

It is important to notice that the argument of typeOf is only used to carry type information via overloading. 
The assumed two features are readily available in Haskell implementations. Of course, a proper language 
extension, which offers adhoc as a built-in, does not need to expose either typeOf or unsafeCoerce. These 
two operations are folklore in the Haskell community because they form the foundation of the Dynamic 
library, which has been a standard part of Haskell distributions for several years. The folk's wisdom to 
derive Typeable and to perform type-safe cast on top of it with the help of unsafeCoerce is found in [p3[]. 
One can also use other, maybe safer, but also more involved approaches to dynamic typing. Regardless of 
the specific approach, the important thing to remember is that our implementational model of adhoc only 
involves term types but no universe such as Dynamic. This means that adhoc is very simple in nature, 
and adhoc is not inherently dynamically typed. 

From the above development it is clear that adhoc is indeed defined in terms of per-type functionality for 
accessing run-time type representations based on overloading. Then, the class Term that captures strategic 
polymorphism has to be constrained by the Typeable class so that every term type is also known to be 
typeable. Thus, we have: 
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class Typeable a =4> Term a where 
— Completed below 



Def. [ii] for the hfoldr combinator immediately necessitates per-type support because Haskell does not 
offer any expressiveness to generically observe the structure of terms. We place hfoldr itself as a member 
in the Term class. In fact, the very comprehensible type of hfoldr from above is not immediately suited 
for an overloaded class member. So we place a primed member in the class with an equivalent type: 

class Typeable a =^ Term a where 

hfoldr' : : \fc. HCons c HNil c — > Parametric a c 

We define hfoldr simply in terms of hfoldr': 

hfoldr :: Vc. HCons c HNil c — > Strategic c 
hfoldr f z = hfoldr' f z 

The type of the primed member uses implicit quantification over the class parameter a. The non-primed 
version uses explicit quantification hidden in Strategic. The Term class exhibits an intriguing feature: it is 
defined recursively in the sense that the Term class itself is used to constrain the signature of its member 
hfoldr' hidden in HCons. This can be viewed as a sign of the first-class status of strategies. 

The classes Term and Typeable can be now added to the Haskell 98 language definition in the same 
way as the standard classes Eq, Ord, Show, and Read. Just as the Haskell language definition contains 
a specification of derived instances for these built-in classes, so do we need to complete our extension by 
specifying the derived Term instances. The derivation of the member hfoldr' is completely straightfor- 
ward. We need to provide one equation per constructor based on the scheme for heterogeneous, right- 
associative fold according to Def. [ii]. That is, given a constructor C of type r with n arguments, we need 
a pattern-match case defined as follows: 

instance Term r where 
hfoldr f z{C Xn ■■■ X2 Xi) = f Xi {f X2 {■ ■ ■ (/ Xn {z C)) ■ ■ •)) 
Continue for the other constructors 

This simple scheme is applicable to mutually recursive, parameterised (perhaps over higher-kinded type 
variables) datatypes. Not even non-uniform recursion is a problem. For all basic datatypes such as Int, we 
assume instances that apply the nil case. This is also a sensible choice for function types as there is no way 
to traverse them but it should be safe to encounter them in the course of traversal. 

For completeness, we have investigated the option to define our combinators by means of derivable type 
classes as they were proposed for Haskell and Clean [ jTsj |]|. Derivable type classes are precisely meant for 
the definition of classes for which the instances follow a common scheme. To this end, polytypic patterns 
for sums and products [ jl^ [T^ ] are included in the pattern-match syntax for class member definition. The 
adhoc combinator (and hence, the Typeable class) does not take advantage of derivable type classes be- 
cause it necessitates a nominal approach rather than structural induction. However, the hfoldr combinator 
(and hence, the Term class) can be defined as follows: 

class Typeable a ^ Term a where 

hfoldrTP :: HCons I —> HNil I —> Parametric a I 

hfoldrTP {| Unit |} / z Unit = z Unit 

hfoldrTP {| a : + : /3 1} / z (/n/ a;) = Inl {hfoldrTP f z x) 

hfoldrTP {\a: + :P\}fz {Inr x) = Inr {hfoldrTP f z x) 

hfoldrTP {| a : * : /3 1} / z (a; : * : ?/) = fx {\x' x' : * : hfoldrTP f z y) 

There are equations for Unit, a :+: /? (i.e., sums), and a (3 (i.e., right-associative products). In fact, we 
only show the special case for the type-preserving scheme where the co-domain constructor is instantiated 
to the identity type constructor /. 
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6 Reconstruction of Strafunski 

The two simple combinators adhoc and hfoldr are sufficient to obtain the full power of strategic program- 
ming. We will demonstrate this by the reconstruction of essential parts of the strategic programming library 
of Strafunski. In fact, all previously published examples of functional strategy combinators [ p5| , pi] , p6| ] 
can be reconstructed with the identified primitives. 

Normally we distinguish two broad categories of strategies, namely type-preserving vs. type-unifying ones. 
In case of the former, input and output term are of the same type. In case of the latter, the output type is fixed 
regardless of the input type. Another dimension of categorisation arises from the issue of possibly 'effect- 
ful' traversal. In previous work, all our strategy combinators adhered to monadic style to be prepared for 
effects such as partiality, environment propagation, and I/O. If no such effect is present, the trivial identity 
monad can be used to 'recover' from monadic style. In the present paper, we explicitly distinguish monadic 
and non-monadic strategies. This allows a strategic programmer to resort to the simpler non-monadic types 
whenever this is sufficient. The variation in the two aforementioned dimensions — type-preservation vs. 
type-unification, and non-monadic vs. monadic strategies — can be captured by the following Haskell type 
synonyms: 

type TP = Va 

type TU u ^ Ma 

type MTP m ^ Ma 
type MTU u m ^ Ma 

Note that these strategy types are just instances of the more abstract type Strategic which we defined in the 
previous section. This can be demonstrated as follows: 

type TP = Strategic I type la —a 

type TU u ~ Strategic {C u) type C u a = u 

type MTP m = Strategic {MI m) type MI ma —ma 

type MTU u m ~ Strategic {MC u m) type MC u m a — m u 

The synonyms /, C, MI, and MC are Haskell implementations of non-monadic and monadic versions of 
the identity and constant type constructors. The four broad categories of strategy types are reconstructed by 
passing one of these type constructors to Strategic. We assume specialised versions of adhoc and hfoldr 
for each of these categories. We postfix the combinators by the corresponding category. These specialised 
combinators shall be used in strategic code if a specific category is intended.^ The speciaUsed combinators 
for the category TP, for example, are declared as follows: 

adhocTP :; Va. Term a =^ TP Parametric a I ^ TP 
hfoldrTP :: HCons I HNil I ^ TP 

These specialisations allow us to maintain "strategy application = function application" in absence of type- 
level lambdas in Haskell. Recall that the types of adhoc and hfoldr involve a parameter c for co-domain 
construction. Any instantiation of the combinator types had to use datatypes or newtypes for c as opposed 
to type synonyms. This is no problem for the category MTP where a monad instantiates c but the other 
categories were defined above via type synonyms for identity and constant type construction. We can easily 
match up the types of adhoc and hfoldr with the simple types favoured by the programmer The trick is to 
wrap and unwrap extra 'coaching' constructors inside the definitions of the specialisations. We illustrate 
this technique for adhocTP: 

newtype I' a = I' a — The newtype variation on / 

unl' {V x) — X — Unwrapping function 

adhocTP f g ~ unl' o adhoc [V o /) (/' o g) — Specialisation of adhoc for TP 

^So we should have used hfoldrMTU instead of hfoldr in the definition of oneMTU in Sec. H. 



. Term a ^ a — > a 
. Term a ^ a u 
. Term a ^ a —> m a 
. Term a ^ a m u 
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At this point, we have defined all helper types and specialised combinators so that strategic programming 
can commence. We can define numerous one-layer traversal combinators in terms of hfoldr, e.g.: 

Attempt to process one child; try from left-to-right 

oneMTU :: Wu m. MonadPlus m MTU u m ^ MTU u m 
oneMTU s ~ hfoldrMTU {Xh t —> t ^mplus^ s h) (const mzero) 

Reduce all children via a monoid 

allTU :: \/u. Monoid u => TU u TU u 

allTU s = hfoldrTU (Xh t t ^mappend^ s h) {const mempty) 

Map over the children 
allTP -.-.TP^TP 

allTP s = hfoldrTP {Xh t ^ t {s h)) id 

Map over the children; monadic variation 

allMTP :: Vm. Monad m =4> MTP m MTP m 

allMTP s = hfoldrMTP {Xh t ^ t Xt' ^ s h return o t') return 

These examples reconstruct combinators as introduced in [p5|]. The first combinator, oneMTU, was al- 
ready defined in Sec. ^ here, we also provide its type, and we use the specialised combinator hfoldrMTU 
to reflect the kind of strategy at hand. There is a class constraint MonadPlus m because oneMTU finds 
the suitable child via try and failure. The second combinator, allTU, uses monoid operations to combine 
the results of applying the type-unifying argument strategy to all children. The third combinator, allTP, is 
a variation on the folklore list map. The type-preserving argument strategy s is mapped over the children 
of a term. In the case of a non-empty constructor application, s is applied to the head h, and then the result 
is passed to the recursively processed tail. The empty constructor application is simply preserved via the 
identity function id. The last combinator, allMTP, is a monadic variation on allTP. It uses monadic bind 
to sequence the applications of the type-preserving argument strategy to all children, and reconstructs 
the term with the processed children. 

Recursive traversal combinators can now be fabricated. The following portfolio provides traversal schemes 
that are parameterised by strategies for node-processing: 

Full traversal of all nodes in top-down manner 

fullMTP :: TP ^ TP 

fulLtdTP s X = allTP {fulLtdTP s) {s x) 

Full traversal of all nodes in bottom-up manner 

fulLbuTP :: TP ^ TP 

fulLbuTP s X = s {allTP (fulLbuTP s) x) 

Top-down traversal with cut after success 

stop.tdMTP :: Vto. MonadPlus m => MTP m MTP m 
stopMMTP s x^ s X 'mplus' allMTP {stop.tdMTP s) x 

Accumulating a list query all-over the place 

collect :: Vm. TU [u] — > TU [u] 

collect s X = s a: -ff allTU {collect s) x 

Selection from the first node that admits success 

select :: m. MonadPlus m MTU u m MTU u m 

select s X = s x ^mplus^ oneMTU {select s) x 
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The first two combinators model non-monadic, type-preserving, and fuU traversal, i.e., they visit every 
node in the input term and the result type coincides precisely with the type of the input type. The monadic, 
type-preserving combinator stop-tdMTP performs a partial traversal, since it does not descend below 
nodes where its argument strategy is applied successfully. The type-unifying combinator collect performs 
a full traversal while intermediate list results are concatenated. The monadic, type-unifying combinator 
select performs a partial traversal following the same scheme as query from the sample section. However, 
the argument for recognition and extraction is not a function on a certain term type, but a strategy. This 
generality is appropriate whenever 'relevant' subterms can be of different types. All these combinators are 
reconstructions of combinators that are available in the strategy library distributed with Strafunski. 

7 Concluding remarks 

We have realized a compact amalgamation of term rewriting strategies and functional programming with 
emphasis on traversal strategies. Functional strategic programming features first-class generic functions 
that traverse terms of any type while mixing uniform and type-specific behaviour. Our reconstruction of 
functional strategies is based on just two combinators. Our first combinator is adhoc for type-based func- 
tion dispatch. Our second combinator is hfoldr for folding over constructor applications. We have given 
concise definitions of the these two basic combinators. We have demonstrated how they are used to define 
one-layer traversal combinators and recursive traversal combinators as used in strategic programming. The 
abilities to traverse terms and to mix uniform and type-specific behaviour provide, in our experience, the 
key to practical application of functional programming to program analysis and transformation problems. 

We have discussed implementational models of functional strategies without commitment to a specific 
functional language. We have, for example, argued that adding built-in support for adhoc and hfoldr to 
functional language implementations requires only modest modifications, if second-order polymorphism is 
available. More specifically, using a reference model which requires generative support per-type, we have 
shown how the Haskell language needs to be extended to include our two combinators. Fully operational 
support for functional strategic programming is available in the form of the Strafunski bundle for generic 
programming and language processing in Haskell. The bundle can be configured to use one out of several 
alternative models. Generative support is based on the DrlFT preprocessing technology for Haskell. Stra- 
funski has been apphed for Java refactoring, Cobol reverse engineering, grammar engineering, Haskell 
program analysis and transformation, XML document transformation, and others. 

Thus, our approach is lightweight, highly expressive, well-founded, and has already proven its value in 
important application domains. Language users take advantage of the generality and simplicity provided 
by our combinator style of generic programming. Language implementors take advantage of the fact that 
strategic programming does not require any new language constructs, but only two simple combinators 
which are easily defined per-type or as built-ins. There is no need for compile-time specialisation, and 
separate compilation is easily maintained. 
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